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REMARKS 

The Examiner has rejected Claims 1, 2, 4, 1 1, 12, 14 and 21 under 35 U.S.C. 
102(e) as being anticipated by Illikkal et al. (U.S. Patent Publication No. 2005/0066028). 
Applicant respectfully disagrees with such rejection, especially in view of the 
amendments made hereinabove to at least some of the independent claims. 

With respect to independent Claim 21, it appears that the Examiner has relied on 
Paragraphs [0030]-[0036] and [0038]-[0044], in addition to Fig. 7 from the Illikkal 
reference to make a prior art showing of applicant's claimed "mechanism for dedicating 
ports to time critical TOE clients." 

Applicant respectfully asserts that the excerpts and figure from the Illikkal 
reference relied upon by the Examiner merely disclose that "the server 200 may receive 
the packet at the offload engine 270 or the host processor 210" (Paragraph [0030]), that 
"the server 900 may be ready to send the packet from the offload engine 270 or the host 
processor 210" (Paragraph [0038]), and that "the offload engine 270 might pre-fetch the 
TCB information and store it in the TCB cache 280 as scheduled" (Paragraph [0035]). 

However, disclosing that the server may receive the packet at the offload engine, 
that the server may be ready to send the packet from the offload engine, and that the 
offload engine pre-fetches the TCB information and stores it in the TCB cache, as in 
Illikkal, simply fails to teach or suggest applicant's claimed "mechanism for dedicating 
ports to time critical TOE clients " (emphasis added), as claimed by applicant. 

In the Office Action dated 05/14/2009, the Examiner has failed to specifically 
respond to applicant's above arguments with respect to applicant's claimed "mechanism 
for dedicating ports to time critical TOE clients," as claimed. Thus, a notice of allowance 
or specific prior art showing of each of the foregoing claim elements, in combination 
with the remaining claimed features, is respectfully requested. 
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The Examiner is reminded that a claim is anticipated only if each and every 
element as set forth in the claim is found, either expressly or inherently described in a 
single prior art reference. Verdegaal Bros. v. Union Oil Co. Of California, 814 F.2d 628, 
631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). Moreover, the identical invention must be 
shown in as complete detail as contained in the claim. Richardson v. Suzuki Motor 
Co.868 F.2d 1226, 1236, 9USPQ2d 1913, 1920 (Fed. Cir. 1989). The elements must be 
arranged as required by the claim. 

This criterion has simply not been met by the above reference excerpts, as noted 
above. Nevertheless, despite such paramount deficiencies and in the spirit of expediting 
the prosecution of the present application, applicant has amended independent Claims 1 
and 1 1 to further distinguish applicant's claim language from the above reference, as 
follows: 

"wherein ports are dedicated to time critical TOE clients" (see Claim 1) and "a 
mechanism for dedicating ports to time critical TOE clients" (see Claim 1 1). 

Applicant respectfully asserts that, as argued hereinabove with respect to 
independent Claim 21, Illikkal teaches that the server may receive the packet at the 
offload engine, that the server may be ready to send the packet from the offload engine, 
and that the offload engine pre-fetches the TCB information and stores it in the TCB 
cache, which simply fails to teach or suggest applicant's claimed technique "wherein 
ports are dedicated to time critical TOE clients " (Claim 1 - emphasis added) and 
applicant's claimed "mechanism for dedicating ports to time critical TOE clients " (Claim 
1 1 - emphasis added), as claimed. 

Again, the foregoing anticipation criterion has simply not been met by the above 
reference excerpt(s), as noted above. Thus, a notice of allowance or specific prior art 
showing of each of the foregoing claim elements, in combination with the remaining 
claimed features, is respectfully requested. 



- 11 - 



Applicant further notes that the prior art is also deficient with respect to the 
dependent claims. For example, with respect to Claim 2, the Examiner has relied on 
Figure 2 from the Illikkal reference to make a prior art showing of applicant's claimed 
techniques "wherein the optional memory stores the CB entries that are directly 
accessible by the CB cache via the port," and "wherein the optional memory also serves 
as main memory for the TOE." Specifically, the Examiner has relied upon "External 
Memory Unit 230" to meet applicant's claimed "optional memory." 

Applicant respectfully asserts that the figure from Illikkal teaches that "[t]o 
perform the TCP/IP processing, the offload engine 270 may need to fetch from the 
'external' memory unit 230 (e.g., external to the NIC 250 ) the TCB information 232 
associated with the appropriate connection" (Paragraph [0018] - emphasis added) and 
that "the NIC 250 may include a local TCB cache 280 that stores TCB information" 
(Paragraph [0019] - emphasis added). 

However, teaching that the offload engine 270 fetches the TCB information 232 
from the 'external' memory unit 230 that is external to the NIC 250 . in addition to 
teaching that the NIC 250 includes a local TCB cache 280 that stores TCB information, 
as in Illikkal, simply fails to suggest applicant's claimed technique "wherein the optional 
memory also serves as main memory for the TOE," especially where "the optional 
memory stores the CB entries that are directly accessible by the CB cache via the 
[dedicated] port" (emphasis added), in the context as specifically claimed by applicant. 
Clearly, the offload engine 270 fetching the TCB information from the 'external' 
memory unit 230 , as in Illikkal, simply fails to even suggest that "the optional memory 
stores the CB entries that are directly accessible by the CB cache via the [dedicated] port" 
(emphasis added), in the context as specifically claimed by applicant. 

With respect to Claim 5 et al., the Examiner has rejected the same under 35 
U.S.C. 103(a) as being unpatentable over Illikkal, in view of Boucher et al. (U.S. Patent 
Publication No. 2002/0156927). Specifically, the Examiner has relied on Figure 4C and 
Paragraphs [0043]-[0044] and [0046] from the Boucher reference to make a prior art 
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showing of applicant's claimed technique "wherein the CB entries are read from the CB 
cache in a word order that is dependent upon a port's purpose." 

Applicant respectfully asserts that the figure and excerpts from Boucher relied 
upon by the Examiner merely teach that "[rjeferring now to FIG. 4C, when a subsequent 
packet from the same connection as the initial packet is received from the network 25 . . . 
the headers are parsed to create a summary of the message packet and a hash for finding a 
corresponding CCB , the summary and hash contained in a word or words ," where "[tjhe 
word or words are temporarily stored in memory 60 along with the packet" (Paragraph 
[0046] - emphasis added). 

However, teaching that word or words are temporarily stored in memory , where 
the word or words contain a summary of the message packet and a hash for finding a 
corresponding CCB, as in Boucher, fails to suggest applicant's claimed technique 
"wherein the CB entries are read from the CB cache in a word order that is dependent 
upon a port's purpose " (emphasis added), as claimed by applicant. Clearly, storing a 
word or words in memory, as in Boucher, simply fails to even suggest "reading] from 
the CB cache in a word order that is dependent upon a port's purpose " (emphasis added), 
as claimed by applicant. 

With respect to Claim 8 et al., the Examiner has rejected the same under 35 
U.S.C. 103(a) as being unpatentable over Illikkal, in view of Banerjee et al. (U.S. Patent 
Publication No. 2002/0165992). Specifically, the Examiner has relied on Paragraphs 
[0020]-[0021] (excerpted below) from the Banerjee reference to make a prior art showing 
of applicant's claimed "comparing the received network packet hash value with the hash 
values in the hash reference table." 

"For example, WEB requests may be assigned a higher priority than 
other connections. Therefore, the listening socket for port 80, 
the WEB server port number, is assigned a high priority in order 
to deliver high performance. Thus, the PCB associated with this 
connection will be stored in the PCB cache. 

According to the present invention, when a packet is received, 
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its associated connection and socket are determined. The PCB 
cache is first searched to try to locate the PCB associated with 
this socket. If the PCB is not found in the PCB cache, the hash 
table or linked list is then searched . If the packet is 
transmitted through a connection having an associated socket 
which is designated as having a high priority, the PCB will be 
stored in the PCB cache, thus, providing a faster response. For 
all lower priority sockets, the associated PCBs will be stored 
and found in the hash table ." (Paragraphs [ 0 02 0 ] - [ 0 02 1 ] - 
emphasis added) 

Applicant respectfully asserts that the excerpt relied upon by the Examiner merely 
discloses that "[i]f the PCB is not found in the PCB cache, the hash table or linked list is 
then searched " and that "[f]or all lower priority sockets, the associated PCBs will be 
stored and found in the hash table " (emphasis added). 

However, merely teaching that if the protocol control block (PCB) is not found in 
the PCB cache, the hash table is then searched , in addition to teaching that for all lower 
priority sockets, the associated PCBs will be stored and found in the hash table , as in 
Banerjee, simply fails to suggest " comparing the received network packet hash value 
with the hash values in the hash reference table" (emphasis added), as claimed by 
applicant. Clearly, searching the hash table, in addition to storing and finding associated 
PCBs in a hash table, as in Banerjee, simply fails to even suggest " comparing the 
received network packet hash value with the hash values in the hash reference table" 
(emphasis added), as claimed by applicant. 

In the Office Action dated 05/14/2009, the Examiner has argued that "with 
reference to Figures 4 & 5 of Banerjee, Banerjee expressly discloses a process flow chart 
with 'steps' which include identifying / creating a PCB for a received packet (steps 502- 
508) storing a PCB entry associated with a socket in a PCB cache (step 414), searching a 
PCB hash table to locate a PCB and do connection processing / using the PCB to locate 
appropriate socket and do connection processing (steps 516-517), as well as the steps of 
'identifying a lowest PCB entry stored in the PCB cache (step 526) and removing the 
lowest priority PCB from the PCB cache and storing it in the regular PCB hash table 
(step 528)." Further, the Examiner has argued that "[bjased on the above disclosures, it is 
clear that the disclosed steps of 'generating' (402) and 'storing a PCB in a hash table' 
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(406), at the very least, teaches that a PCB entry is created for a packet, and then entered 
into a PCB 'Hash Table'," that "[i]t is thus clear that the individual 'entries' of a PCB 
Hash Table are themselves necessarily 'hashed' or must have a field / parameter 
component comprising a 'hash value'," and that "[a]s such, it is thus obvious to one of 
ordinary skill that 'searching' a PCB Hash Table to identify or 'locate' a particular PCB 
(specific PCB 'hashed' entry or PCB with a 'hash value' parameter) associated with a 
'connection' and in relation to the receipt of a packet, clearly implies that the PCB 'hash 
value' of a received packet is being 'matched' or compared to 'hashed' entries of a PCB 
Hash Table to identify / locate the particular PCB." 

Applicant respectfully disagrees and asserts that Figure 4 of Banerjee merely 
teaches that "[a] protocol control block (PCB) is also created which is associated with 
this socket," where "[i]f a determination is made that this is not a high priority 
connection, the process passes to block 406 which illustrates storing the PCB associated 
with this socket in a hash table " (Paragraph [0046] - emphasis added). 

Further, applicant asserts that Figure 5 of Banerjee teaches that "block 502. . . 
illustrates a receipt of a packet," that "block 504 depicts using the source and destination 
addresses, and the local and destination port numbers obtained from the packet to identify 
a particular PCB associated with the connection through which this packet was 
transmitted" and that "block 508 depicts searching the PCB table for this PCB " 
(Paragraph [0049] - emphasis added). Additionally, applicant asserts that Figure 5 of 
Banerjee teaches that "[Referring again to block 510, if a determination is made that the 
PCB was not found in PCB cache 208 A, the process passes to block 516 which illustrates 
searching the PCB hash table to locate the PCB and executing connection processing" 
(Paragraph [0051] - emphasis added). 

However, storing the protocol control block (PCB) associated with a socket in a 
hash table , in addition to using the source and destination addresses, and the local and 
destination port numbers obtained from the packet to identify a particular PCB , and 
searching the PCB table for this PCB , and further searching a PCB hash table to locate 
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the PCB, as in Banerjee, fails to suggest a "received network packet hash value," much 
less applicant's specifically claimed " comparing the received network packet hash value 
with the hash values in the hash reference table" (emphasis added), as claimed by 
applicant. Clearly, using the source and destination addresses , and the local and 
destination port numbers to identify a particular PCB, and searching the PCB table or the 
PCB hash table for this PCB , as in Banerjee, simply fails to even suggest " comparing the 
received network packet hash value with the hash values in the hash reference table" 
(emphasis added), as claimed by applicant. 

In addition, storing the protocol control block (PCB) associated with a socket in a 
hash table , in addition to searching the PCB table or the PCB hash table for this PCB , as 
in Banerjee, simply fails to support the Examiner's allegation that "it is thus obvious to 
one of ordinary skill that 'searching' a PCB Hash Table to identify or 'locate' a particular 
PCB... associated with a 'connection' and in relation to the receipt of a packet, clearly 
implies that the PCB 'hash value' of a received packet is being ' matched' or compared to 
'hashed' entries of a PCB Hash Table to identify / locate the particular PCB" (emphasis 
added), as alleged by the Examiner. 

Therefore, applicant has adequately traversed the Examiner's assertion of Official 
Notice, and thus formally requests a specific showing of the subject matter in ALL of the 
claims in any future action. Note excerpt from MPEP below. 

"If the applicant traverses such an [Official Notice] assertion the examiner should 
cite a reference in support of his or her position." See MPEP 2144.03. 

Additionally, it appears that the Examiner has relied on an inherency argument 
regarding the above emphasized claim limitations. In view of the arguments made 
hereinabove, any such inherency argument has been adequately rebutted, and a notice of 
allowance or a specific prior art showing of such claim features, in combination with the 
remaining claim elements is respectfully requested. (See MPEP 2112) 
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Further, in response, applicant asserts that the fact that a certain result or 
characteristic may occur or be present in the prior art is not sufficient to establish the 
inherency of that result or characteristic. In re Rijckaert, 9 F.3d 1531, 1534, 28 USPQ2d 
1955, 1957 (Fed. Cir. 1993); In re Oelrich, 666 F.2d 578, 581-82, 212 USPQ 323, 326 
(CCPA 1981). "To establish inherency, the extrinsic evidence 'must make clear that the 
missing descriptive matter is necessarily present in the thing described in the reference, 
and that it would be so recognized by persons of ordinary skill. Inherency, however, may 
not be established by probabilities or possibilities. The mere fact that a certain thing may 
result from a given set of circumstances is not sufficient.'" In re Robertson, 169 F. 3d 
743, 745, 49 USPQ2d 1949, 1950-51 (Fed. Cir. 1999). 

With respect to the rejection under 35 U.S.C. 102(e), the foregoing anticipation 
criterion has simply not been met by the above reference excerpt(s), as noted above. 

With respect to the rejection under 35 U.S.C. 103(a), to establish a prima facie 
case of obviousness, three basic criteria must be met. First, there must be some 
suggestion or motivation, either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art, to modify the reference or to 
combine reference teachings. Second, there must be a reasonable expectation of success. 
Finally, the prior art reference (or references when combined) must teach or suggest all 
the claim limitations. The teaching or suggestion to make the claimed combination and 
the reasonable expectation of success must both be found in the prior art and not based on 
applicant's disclosure. In re Vaeck,9Al F.2d 488, 20 USPQ2d 1438 (Fed.Cir.1991). 

Applicant respectfully asserts that at least the third element of the prima facie 
case of obviousness has not been met, since the prior art excerpts, as relied upon by the 
Examiner, fail to teach or suggest all of the claim limitations, as noted above. 

Thus, a notice of allowance or a proper prior art showing of all of applicant's 
claim limitations, in combination with the remaining claim elements, is respectfully 
requested. 
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To this end, all of the independent claims are deemed allowable. Moreover, the 
remaining dependent claims are further deemed allowable, in view of their dependence 
on such independent claims. 

In the event a telephone conversation would expedite the prosecution of this 
application, the Examiner may reach the undersigned at (408) 505-5100. The 
Commissioner is authorized to charge any additional fees or credit any overpayment to 
Deposit Account No. 50-1351 (Order No. NVIDP342). 

Respectfully submitted, 
Zilka-Kotab, PC 
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